Some further description:

The get_native method for a sycl::context currently maps to a single native CUcontext. The CUDA backend spec KhronosGroup/SYCL-Docs#420 for SYCL specifies that a sycl::context should map to a vector of native contexts. However this PR is still unmerged meaning this mapping cannot be integrated into the core API. For this reason we have two separate versions of get_native<backend::ext_oneapi_cuda, sycl::context>. One is the standard core SYCL spec version and the other can be found here https://github.com/intel/llvm/blob/sycl/sycl/include/sycl/ext/oneapi/experimental/backend/cuda.hpp#L38 which can be used if the macro SYCL_EXT_ONEAPI_BACKEND_CUDA_EXPERIMENTAL is defined.

This dual impl has been harmless up until now since the context has been constrained to a single device. However #10737 introduces behaviour that if we have two devices in a single platform (ie two CUDA devices) then the default context will contain them both. Therefore if users are using the experimental interface for get_native which returns a vec of CUcontexts, the correct behaviour will be guaranteed. Whereas if users are using the standard interface which returns a single CUcontext this get_native will return the native context of the first device in the sycl::context. This could lead to tricky bugs in user code as well as cases where only the first context in a sycl::context is usable, making the interop interface unintuitive and cumbersome.

For this reason I think it is better to deprecate the get_native interface for sycl::context for CUDA and HIP backends, and instead encourage users to get the native context by calling [cu|hip]DevicePrimaryCtxRetain with a native device.

Ping @intel/llvm-gatekeepers can we merge this please?

Ping @intel/llvm-gatekeepers can we merge this please?

check-sycl has failed.

Ping @intel/llvm-gatekeepers can we merge this please?

check-sycl has failed.

It seems that interop-cuda.cpp is being run for the AMD triple, even though REQUIRES: cuda is being used. I am not sure what's happening here but will restart the CI.

@aelovikov-intel test should be fixed now, but still surprising that this is running for the AMD triple

@aelovikov-intel test should be fixed now, but still surprising that this is running for the AMD triple

I think the semantics of LIT features might be different between sycl/test and sycl/test-e2e. #10635 could also be related somehow.

I'm not driver expert, but might it be that we specify some options to be used when targeting AMD, but then don't actually target it? IMO, that would be consistent with the "argument unused during compilation" warning we saw in that test run.